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REMARKS 

This Amendment and the following remarks are intended to fully respond to the Final 
Office Action mailed December 19, 2005. In that Office Action, claims 1-6 and 8-20 were 
examined, and all claims were rejected. Specifically, claims 1-6 and 8-20 stand rejected under 
35 U.S.C. § 103(a) as being unpatentable over Hafsteinsson et al. (US Patent App. Pub No. 
2004072484A1). Reconsideration of these rejections, as they might apply to the original and 
amended claims in view of these remarks, is respectfully requested. 

In this Response, no claims are amended and no claims have been canceled. Claims 1-6 
and 8-20 remain present for examination. 

Claim Rejections - 35 U.S,C. § 103 

Claims 1-6 and 8-20 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Hafsteinsson et al. (U.S. Patent App. Pub. No. 2004072484A1), hereinafter "Hafsteinsson." 
Specifically, the Examiner asserts that Hafsteinsson discloses determining a capability of a 
device and retrieving information about an adapter set based on the capability of a device. 
Applicants respectfully traverse this rejection. Applicants submit that the specific portions of 
Hafsteinsson relied on by the Examiner to reject claims 1-6 and 8-20 are not entitled to the 
priority date of Provisional Patent Application No. 60/194,695 (April 5, 2000) hereinafter 
"provisional." The provisional is included below as Appendix A. Applicants have previously 
established (see Office Action Response dated April 13, 2005) that the present invention has a 
conception and an actual reduction to practice that predates at least September 6, 2000. 

Hafsteinsson relates to a method for communicating between a transmitting device and a 
receiving device. See Hafsteinsson, page 1, paragraph [0006]. The method includes converting 
source data in a first format as output from the transmitting device into a second format to be 
received by the receiving device. See Hafsteinsson, page 1, paragraph [0006]. The converting 
step is separated into tv^o steps. The first step includes converting data fi"om the first format into 
an intermediate device independent format. See Hafsteinsson, page 1, paragraph [001 1]. The 
second step includes converting the data from the intermediate device independent format to a 
second device specific format. See Hafsteinsson, page 1, paragraph [001 1]. 
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The priority date of a parent application can be accorded to a CIP (or child applications of 
the CIP) for only that material presented in the parent application. See William Pordy v. Land 
O' Lakes, Inc., 97 Fed. Appx. 921, 929 (Fed. Cir. 2004). The Examiner asserts that the portions 
of Hafsteinsson cited in the Office Action to reject the claims are reflected in the provisional, and 
are thus entitled to the priority date of April 5, 2000. The Applicants respectfiilly disagree with 
the Examiner's reading of the provisional. The Applicants submit that the provisional does not 
disclose the elements of the claims, and therefore any disclosures in Hafsteinsson that the 
Examiner interprets as disclosing the elements of the claims are not supported by the disclosure 
in the provisional. 

The provisional generally describes a process for converting data in a first format as 
output fi*om a web server into a second format to be received by a device, or for conversion of 
data in the second format into data in the first format. See Provisional, page 1 , line 34-page 2, 
line 3. The provisional does not make any mention of determining a capability of a device or 
retrieving information about an adapter set based on the capability of a device, as claimed in the 
claims. 

The provisional states that conversion of data is based on conversion rules related to the 
requested data. See Provisional, page 3, lines 12-14. The provisional is clear that the specific 
conversion or transformation used to convert the data is determined by the client request. As the 
provisional explains, "a client sends in parameters to the system requesting a certain URL, which 
contains an HTML document and what transformation to use to transform the HTML." 
Provisional, page 6, lines 10-12. The provisional further states that to transform the data, "the 
system checks if a transformation document with the given name exists." Provisional, page 7, 
line 26. There is nothing in the provisional indicating that a capability of a device is ever 
determined. Moreover, because the request already contains the specific transformation to use 
for conversion of the data, there is no need to determine a capability of the device, much less use 
the determined capability of a device to retrieve information about an adapter set. 

Although the Applicants do not admit that the elements of the claims noted above are 
found in Hafsteinsson, it is clear that the provisional does not provide support for these elements, 
even if the Examiner believes that they are disclosed in Hafsteinsson. Accordingly, the subject 
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matter of Hafsteinsson cited by the Examiner to reject the claims of the present application is not 
entitled to the priority date of the provisional, and consequently is not prior art. 

The Applicants respectfully submit that the Examiner has failed to establish a prima facie 
case of obviousness, because the Examiner has failed to cite prior art references that disclose all 
the elements of the claims. 
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Conclusion 

This Amendment fully responds to the Final Office Action mailed December 19, 2005. 
Still, that Office Action may contain arguments and rejections that are not directly addressed by 
this Amendment due to the fact that they are rendered moot in light of the preceding arguments 
in favor of patentability. Hence, failure of this Amendment to directly address an argument 
raised in the Office Action should not be taken as an indication that the Applicant believes the 
argument has merit. Furthermore, the claims of the present application may include other 
elements, not discussed in this Amendment, which are not shown, taught, or otherwise suggested 
by the art of record. Accordingly, the preceding arguments in favor of patentability are advanced 
without prejudice to other bases of patentability. 

It is believed that no fees are due with this Response. However, the Commissioner is 
hereby authorized to charge any deficiencies or credit any overpayment with respect to this 
patent application to deposit account number 13-2725. 

In light of the above remarks and amendments, it is believed that the application is now 
in condition for allowance and such action is respectfully requested. Should any additional 
issues need to be resolved, the Examiner is requested to telephone the undersigned to attempt to 
resolve those issues. 



Respectfully submitted, 



Date: February 21, 2006 





PATEhfT TRADEMARK OFFICE 



Minneapolis, Minnesota 55402-0903 
(303)357-1637 



Page 9 of 9 



Box ProTiitooa] ApplkatioD 

PTO/SB/16(6-95) 

PROVISIONAL APPUCATION FOR PATENT COVER SHEET 

Hiis is a request for filing a PROVISIONAL APPLICATION FOR PATENT under 37 C.F.R. § 1.53 (c). 



Filing Date 


April 5, 2000 


Docket Number 


0459-042 IP 


INVENT0R(8yAPPLICANT(») 


LAST NAME 


FIRST NAME 


MIDDLE IMTIAL 


KEStDQfCE tart AND ETTHEB 
STATE (A FOREIGN COUNTRY) 


Hafsteinsson 
Ludviksson 


Gudmundur 
Georg 




Reykjavik, Iceland 
Reykjavik, Iceland 


TTILE OF THE INVENTION (280 characters max) 


A SYSTEM FOR WIRELESS COMMUNICATION OF DATA BETWEEN A WS^ 
DEVICE USING A WIRELESS APPLICATION PROTOCOL 


CX)RJR£SPOND£NCE ADDRESS 


Birch, Stewart, Kolasch & Birch, LLP 
P.O. Box 747 
Falls Church 


STATE 


VA 


ZIP CODE 


22040-0747 


COUNTRY 


U.S.A. 


ENCLOSED APPUCATION PARTS (check aU that a^ly) 


^ Specification 
^ Drawiiig(s) 


Number qf Pages: Xi 
blmber of Sheets: 2 




n Small Entity Sutemeu 
n Other fspeciftr^: 


METHOD OF PAYMENT (check one) 


PROVISIONAL FILING FEB 


13 A check or money order is enclosed to cover the Provisbnal filing fees. 




□ Small Entity ($75.00) 


Q The Conmussioner is hereto audiorized to charge fil^ 
Number 02-2448, if oecessaiy. 


^ Lai;ge Entity ($150.00) 



The invention was made by an agency of the United States Government or under a contract with an agency of the 
United States Government. 



S No. 

Q Yes. the name of the U.S. Government agency and the Government contract number are: 



Respectfully submitted, 



Date: April 5, 2000 



JAC:mdp 
045SMM21P 



BIRCH. STEWART. KOLASCH & BIRCH. LLP 





. Castellano. #35,094 
P.^ox747 

Falls Qurch, VA 22040^47 
(703)205-8000 



Q Additional inventors are being named on separately numbered sheets attached hereto. 



1 



A SYSTEM FOR WIRELESS COMMUNICATION OF DATA BETWEEN A WEB SERVER 
AND A DEVICE USING A WIRELESS APPLICATION PROTOCOL 

Field of the Invention 

5 The present invention relates to a system and a method for communication of data 
between a WEB server and a device using a wireless application protocol, such as a WAP 
mobile phone. The invention further relates to a method of dynamic, cheaper and faster 
conversion of data between a first and a second fonnat compliant to the WEB server and 
the device. 

Description of the Prior Art 

Primarily due to differences in data formats there are currently no means for reading data 
comprised in e.g. a HTML WEB page from a WAP phone. In order to access WEB page 
Information from a WAP phone, the WEB pages has to be converted. Today the owner of 
a WEB page typically selects specific data from the WEB page that he wants to make 
accessible from a WAP phone. The data is then converted and a new data file containing 
the converted data is created. When a WAP phone customer enters the spedftc WEB 
page, it is in reality the data file containing the converted data that is entered. 

Due to the duplication of the WEB page infonmation, two data files having different 
content, even though they disclose the same information, have to be updated. This is both 
costly and time consuming. Moreover the risk of faults are higher given that two pages 
must provide identical information in different formats. 

It is the purpose of the present invention to enable access to a WEB page directly from 
such devices as WAP mobile phones by means of inline conversion of data instead of 
duplication of data Accordingly the cost of creating a WAP service, if the same service is 
at hand in a HTML WEB page can be lowered, the risk of faults can be lowered and the 
costs for maintenance of "WAP accessible" WEB pages can be reduced. 

General Description of the Invention 

According to one aspect the invention relates to a system for wireless communication of 
data between a WEB server and a device using a wireless application protocol. The 
35 system comprises a converter for inline conversion of data in a first format as output from 
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the WEB server into a second format to be received by the device or for conversion of 
data tn the second format into data in the first fonnat The converter may be a processor 
adapted In a computer system of any Idnd, such as in a PC. The two data fomiats could 
be HTML and WML or any other formats adapted for the two platfomis - the WEB sen/er 
5 and the WAP device. Inline conversion means that the conversion takes place when a 
WAP device user requests information comprised in a WEB page, so that the client 
receives information comprised in the actual WEB page and not information from the 
WEB page that has earlier been converted. 

10 According to a preferred embodiment of the Invention the converter may comprise a 
computer database wherein output data generated in response to input data is controlled 
by an identifler of the WEB server data. The identification could be based on a user 
defined relationship between a number of WEB pages and matching schemas comprising 
conversion rules for the WEB pages. When a WEB page owner decides to enable 

15 conversion of the WEB page into a WAP device compliant format such as WML 

The conversion rules may be grouped into the schemas e g. based on various versions of 
the two formats e.g. various versions of HTML, XML or WML or they may be grouped 
based on the type of infonnation being converted. 

20 

According to a prefened embodiment of the invention the first format is HTML, XML or a 
XML compliant format and the second fonrat is WML or a similar a WAP compliant 
fomiaL If the WEB page is in HTML the HTML could preferably be pre-converted into XML 
and then the XML fonnat could be converted into WML based on a conversion njle 
25 schema. 

The system should preferably be adapted to support cun-ent standards and most 
commonly used methods and fomiats such as the http and the SSL connections. 

30 The system could be implemented in a regular computer system, e.g. implemented in the 
WEB server and preferably the implementation could be performed by means of platform 
independent tools such as Java. 
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According to another aspect the invention relates to a method for conversion of data in a 
first format as output from a WEB server into a second forniat to be received by a device 
using a wireless application protocol said method comprising the steps of inline: 

5 - reading from the device a request for data from a WEB server address, 

• converting the request from a first data format to a second data format, 
- fonvarding the converted request to the WEB server, 

. receiving data from the WEB server address, 

• converting the data from the second data format to the first data fomnat. 
10 - forwarding the data to the device. 

Preferably the conversion may be based on a set of conversion rules related to the 
requested data and preferably such mies are grouped in templates based on 
characteristics of the requested data e.g. ^e data format of the requested data etc. The 
15 owner of a WEB page can then chose between a number of conversion templates for 
conversion of a specific WEB page. 

Brief description of the drawings 

A system based on a preferred embodiment of the invention will now be described in 
20 detail with reference to the drawings in which; 

Fig. 1 shows a general overview of a system according to the present invention. 
Fig. 2 shows an overview of the transformation process. 

25 Detailed description of the invention 

The invention will in the following be described by means of an example of a system for 
conversion of data formats for exchange of data between a WEB sen/er and a WAP 
device. The system makes It quicker and cheaper than currently possible to publish HTML 
content in a WAP device. By use of the system, any existing HTML content can be 

30 transformed to the WAP device's native fomnat WML. Therefore virtually any service 
currently available on the Internet can be made available to WAP devices in a matter of a 
few hours or days. 

The system acts as a Uttering proxy, meaning that it processes and alters all requests 
35 from the WAP device and all responses from the HTML web server. No atterations are 



20953AU1/PeW 



APR-04-2000 09:12 



PU&P 3363960e 



needed on the server as lorg as it is at least HTTP 1 .0 compliant and as long as the WAP 
device is compliant it should be able to display the response given fron^ the system (since 
it is fully compliant with the WAP standard as defined by the WAP forum). A general 
overview is shown in Fig. 1 in which the system is shown in blue. 

5 

The functionalit/s of the system can be grouped into two parts. First of all it transforms 
HTML content into WML content which can be displayed on WAP devices. Secondly it 
handles requests from WAP devices and responses from web servers, serving HTML 
content. A part of that process is to offer functlonaiity not available in current WAP 
10 devices, such as cookies, and also to save bandwidth, e.g. by caching big HTML 
parameters. Each part will now be described separately. 

The system is preferably a Java application that is run as a servlet within a seivtet engine. 
Currently the system has been tested on Apache with JServ as servlet engine, both on 
Linux and Windows NT server and workstation platforms, and on IIS with Jrun as servlet 
engine running on Windows NT. It is developed on a Windows NT server running Apache 
1.3.1 1 with JServ 1.1, and Is periodically deployed on a Linux computer running RedHat 
6.1 and Apache 1.3.12 with JServ 1.1. The system should be able to run on any JSDK 2.0 
compliant servlet engine on any platfonm without modifications. 

The purpose of the filtering process is to take an HTML web page and transfonm rt into a 
WML page which WAP devices can read. The process is not automatic in the sense that 
all pages can be converted by the means of a single transformation, but rather that certain 
HTML pages or URLs that refer to HTML pages are paired with a certain transformation 
document. When the HTML content changes (not the layout) the WML page changes 
simultaneously as it is always transformed from the same dynamic HTML page. A given 
HTML page can be transfomied into many WML pages by using many different 
transformations. 

30 Fig. 2 shows how HTML files are transferred into XML and then into WML. 

According to a preferred embodiment of the system all transfomiations are written using 
the generic transformation language XSLT which is a W3C recommendation and is part of 
the XSL standard's working draft. The problem is that XSL only works for well fomied 
35 XML documents, and so the HTML content must be converted into XML before being 
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processed with XSL. In order to make this change, the HTML document is put through a 
so called tidy process, which transfo/ms a genenc HTML document into a well formed 
(and legal) XML document. This may be done with a publicly available application called 
Tidy which takes an HTML input stream and gives out an XML output stream. 

5 

This part is marked numbered (5) in Pig. 2. 

Given the XML version of the HTML document, it is put through an XSL transfomnation 
process. This is a highly standardised and very well documented process. 

10 

The communication part hands a reference to the transfomiation document to the 
transformation part. Preferably it is passed in as a parameter in the HTTP GET request 
from the WAP device, but other possibilities could be used without altering the filtering 
process itself. 

15 

All transformations are currently stored as files on the sen/er that the system is running 
on. All files are encrypted e.g. with a 1024 bit private RSA key to ensure they can neither 
be inspected nor tampered with. 

20 All license information is stored in specific license files, one for each domain, each 
specifying which domain($) is/are a part of that license, how many concurrent sessions 
can be active and the timeout for each session. The license files are encrypted with the 
same private key as the transformation files. 

25 The system is a servlet that is run on any network connected servlet enabled web server 
The physical and logical location of that server is not relevant, as long as connections can 
be made to the requesting dient and the serving sen/er. The following details the process 
that the system follows. 

30 1 . A client requests a connection with the system servlet. How this is mapped to an 
URL depends on the servlet engine the system is running on. The system then 
connects to the serving server and retrieves the requested HTML document. How 
this is done is described in detail below. 
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2. Given an HTML document and an XSL document the document is transformed 
into a WML document. How this is done is described In detail in the 
Transfbrmstion Process section below. 

3. The WML document is sent back to the client along with appropriate sender 

5 response headers which the serving server sent back to the system. How this is 
done in detail is described in detail in the Response Process section below. 

The connection process is as follows: 

10 1 . The client sends in parameters to the system requesting a certain URL which 
contains an HTML document and what transformation to use to transform the 
HTML document 

2. The requested URL is transmitted with a parameter e.g. called urX, which is a 
normal URL except for all ampersands (&} are converted to exclamations (!}. This 

1 5 conversion is done so thai system does not attempt to respond to parameters that 
are given in the URL. 

3. The requested transformation is given with a parameter e.g. called xxx. This is a 

unique name which is mapped to a certain transfbmiation document which is of 
type XSL. How this name is interpreted depends on the Transformation Process. 
20 4. If a session does not exist for the connection a new one is made. Session control 
is done through the servlet engine which supports sessions with URL rewriting, 
which is necessary as WAP dew:e5 do not cunently support cookies. 

5. The system does next a license check. Licenses are described in enciphered 
license files and are read in beforehand and kept in memory. Licenses describe 

25 what domains may be accessed through that license, how many concun'ent 
connections can connect through that license and the length of the timeout for 
sessions through that license. 

6. The system makes a connection to the URL given by the client and forwards 
certain request parameters. What parameters are forwarded depends on the 

30 HTTP 1.1 standard as described in RFC-2616. The system acts as a proxy in this 
case. 

7. The following headers are currently fonvarded: 
Accept -Char set 

35 User-Agent 
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Authorization 

In addition the following headers are sent: 

Via - the system and version number is added to the received Via header 
Accept - Is set to "text/html, texl/vnd,wap.wmr. 
5 connection - Is set to 'Close" in conformance with RFC-2816. 

Cookie - Is set according to what cookies have been set by the server for that 
session within that domain. Cookies are described in RFC-2109. 
8. The system performs the same type of request to the server as the client did to the 
system, e.g. GET or POST. 

10 9. The system sends all request parameters sent by the client except when the client 
requests a server side parameter caching. In that case all parameters are cached 
until the next request from that session that does not request caching Is done, in 
which case they are sent with other parameters of the request. This is used as a 
workaround for some WAP devices limiting the length of the GET and POST 

1 5 request strings (sometimes to as little as 1 27 bytes). 

10. All response headers and the response code are kept for the Response Process 
and then the connection is closed in conformance e.g. with RFC-2616 (the HTTP 
1.1 standard). 

11. The system preferably supports both normal http and SSL (https) connections. 

20 The nonna] http connectkin is implemented by the standard Java package java.net 
and the SSL connection is implemented by the reference implementation of JSSE 
by Sun which is a royalty firee Imptementation which may be used in commercial 
applications. 

25 The transformation process may be as follows; 

1 . TYie system checks if a transformation document with the given name exists. 
Currently all transformation documents are XSL, which is a working draft due to 
become an open standard and is described by World Wkle Web Consortium. All 
transformations are stored enciphered on the local disk and read In beforehand for 

30 added perfonmance. The endphering code is a clean house implementadon of the 
JCE (Java Cryptography Extension) interface as defined by Sun. implemented by 
eSec Ltd. which is licensed under ABA Public License. 

2. The HTML document is run through a cleaning process called Ttdy. This process 
is necessary to tunfi the HTML document into an XML compliant document, 

35 because XSL can only transform XML compliant documents. The tkiy process may 
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either be implemented as part of the system or it may l>e executed as an external 
process. The Tidy component may be obtained as a royalty free component which 
may be used in commercial applications. 

3. The tidied HTML document (hereafter called the XML document) is transformed 

5 with the given transformation document. Before this transformation process is run 
a few XSL variables are added to the transformation document on the fly in order 
to aid the transformation process. The variables are: 
waporllRL - The URL of the system. This is done in order to make the system 
more portable and to maintain any sessions that may be going on. 
1 0 param - A general passing parameter passed in by the client and may be used by 
the transformation process in any way. Currently there is only one parameter but it 
is planned to make a general mechanism in order to allow any number of 
parameters. 

These parameters are only visible in the current transformation and are not the 
15 same as WML variables. 

4. The transfomiation process is currently implemented by XT. XT also uses an XML 
parser from IBM,XML4J. 

5. The output of this transformation process (a WML document) is sent to the 
Response Process. 

20 

The response process may be as follows: 

1 . The system already has an open connection to the dient and fonvards certain 
HTTP headers from the senring sender as described in RFC-2616 (the HTTP 1.1 
standard). 

25 The headers that are forwarded are: 
www - au then t i ca t e 
server 

cache -control 

30 2. The system sends the response code from the server. 

3. The system sends the WML document which was the result of the transfonmation 
process to the dient. 

Preferred technical features of the system are: 

35 
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- Platform independence, which can reside anywhere between the mobile user and 
the HTML content 

- Use of open standards. 

• Support of secure connections (SSL and TLS). both incoming and outgoing. 
5 - Support of cookies and session control. 

. Graphical interface for aeating transfoonations quickly and easily. 
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Claims 

1 . A system for wireless communication of data between a WEB server and a device 
using a wireless application protocol, comprising a converter for inline conversion of data 

5 in a first format as output from the WEB server into a second format to be received by the 
device or for conversion of data in the second format Into data in the first formal 

2. A system according to daim 1 , wherein the converter compnses a computer database 
wherein output data generated in response to Input data Is controlled by an identifier of 

10 the WEB server data. 

3. A system according to claim 1 or 2, wherein the identifier of the WEB server data 
selects a pre-spedfted conversion rule scheme based on a pre-ciassfftcation of the WEB 
server data. 

15 

4. A system according to any of the preceding claims, wherein the first format is an XML 
compliant format and wherein the second fomiat is a WAP compliant format. 

5. A system according to any of the preceding dalms, wherein the first format is HTML 
20 and wherein the second fomnat is WML 

6. A system according to daim 5, wherein the first format Is converted into an intermediate 
fonnat and wherein the intermediate format is XML. 

25 7. A system according to any of the preceding claims, wherein the system is adapted to 
support the http and the SSL connections. 

8. A system according to any of the preceding daims, wherein the system Is implemented 
in a computer system by means of Java. 

30 

9. A method for conversion of data in a first format as output from a WEB sen/er into a 
second format to be received by a device using a wireless application protocol said 
method comprising the steps of inline: 

35 - reading from the device a request for data from a WEB server address, 
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* converting the request from a first data format to a second data format, 

• forwarding the converted request to the WEB sen/er, 

- receiving data from the WEB server address. 

- converting the data from the second data format to the first data format, 
5 - forwarding the data to the device. 

10. A method for conversion of data according to claim 9, wherein the conversion Is based 
on a set of conversion rules related to the requested data. 

10 1 1 . A method for conversion of data according to claim 9 or 1 0. wherein the set of 
conversion rules are grouped into conversion templates according to characteristics of the 
requested data. 

1 2. A method for conversion of data according to claim 1 1 , wherein a group of conversion 
15 rules are selected in relation to requested data. 
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